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(54) lUlethod and apparatus for providing proxying and transcoding of documents in a distributed 
metwork 

(57) A metliod of providing a document to a client 
coupled to a server is provided. TTie server provides a 
number of Internet services to the client, including func- 
tioning as a caching proxy on behalf of the client for pur- 
poses of accessing the World Wide Web. The proxying 
sender includes a persistent document database, which 
stores various attributes of all documents previously 
retrieved in response to a request from a client. When a 
Web document is retrieved from a remote server in 
response to a request from the client, the database is 
consulted and the stored information relating to the 
requested document is used by the server in transcod- 
ing the document The document is transcoded for vari- 
ous purposes, including to circumvent bugs or quirks 
found in the document to size the document for display 
on a television set. to improve transmission efficiency of 
the document, and to reduce latency The transcoder 
makes use of the document database to perform these 
functions. The document database is also used for 
prefetching previously requested documents and 
images and for reducing latency when downloading 

images to the client -■ 
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Description 

FIELD OF THE INVENTiQN 

The present invention pertains to the field of client- 
server computer networking. More particularly, the 
present invention relates to a method and apparatus for 
providing prcxying and document transcoding In a 
server in a computer network. 

BACKGROUND O F THE INVENTIQN 

The number of people using personal computers 
has increased substantially in recent years, and along 
with this increase has come an explosion in the use of 
the Intemet. One particular aspect of the Internet which 
has gained widespread use is the World-Wide Web 
("the Web^. The Web is a collection of formatted hyper- 
text pages kx^ated on numerous computers around the 
workJ that are logically connected by the Internet 
Advances in network technology and software providing 
user Interfaces to the Web fWeb browsers") have made 
the Web accessible to a targe segment of the popula- 
tion. However, despite the growth in the development 
and use of the Web, many people are still unable to take 
advantage of this important resource. 

Access to the Web has been limited thus far mostly 
to people who have access to a personal computer 
However, many people cannot afford the cost of even a 
relatively inexpensive personal computer, while others 
are either unable or unwilling to learn the basic compu- 
ter skills that are required to access the Web. Further- 
more. Web browsers in the prior art generally do not 
provide the degree of user-friendliness desired by some 
people, and many computer novices do not have the 
patience to leam how to use the software. Therefore, it 
would be desirable to provide an inexpensive means by 
which a person can access the Web without the use of 
a personal computer. In particular, it wouki be desirable 
for a person to be able to access the Web pages using 
an ordinary television set and a remote control, so that 
the person feels more as if he or she is simply changing 
television channels, rather than utilizing a complex com- 
puter network. 

Prior art Web technology also has other significant 
limitations which can make a person's experience 
unpleasant when browsing the Web. Web documents 
are commonly written in HTML (Hypertext Mark-up Lan- 
guage). HTML documents sometimes contain bugs 
(enors) or have features that are not recognized by cer- 
tain Web browsers. These bugs or quirks in a document 
can cause a Web browser to fail. Thus, what Is needed 
Is a means for reducing the frequency with which client 
systems fail due to bugs or quirks in HTML documents. 

Another problem associated with browsing the Web 
is latency. People commonly experience long, frustrat- 
ing delays when browsing the Web. It is not unusual for 
a person to have to wait minutes after selecting a hyper- 
text link for a Web page to be completely downfoaded to 



his computer and displayed on his computer screen. 
There are many possible causes for latency, such as 
heavy communications traffic on the Internet and slow 
response of remote servers. Latency can also be 

5 caused by Web pages including images. One reason for 
this effect is that, when an HTML document references 
an image, it takes time to retrieve tiie image itself after 
the referencing document has been retrieved. Another 
reason is that, in the prior art. if the referencing docu- 

10 ment does not specify the size of the image, the client 
system generally cannot display the Web page until the 
image itself has been retrieved. Numerous otiiers 
sources of latency exist with respect to the Web. There- 
fore, what is needed is a means for reducing such 

75 latency, to eliminate some of tiie frustration which typi- 
cally has been associated with browsing the Web. 

Security is anotiier concern assodated with the 
Internet. Intemet service providers (ISPs) generally 
maintain certain information about each customer in a 

20 database. This information may include information 
which a customer may not wish to become publicly 
known, such as social security numbers and credit card 
numbers. Maintaining the conrfidentiality of this informa- 
tion in a system that is connected to an expensive pub- 

25 licly-accessible computer network like the Internet can 
be problematic. Further, the problem can be aggravated 
by the fad ttiat an ISP often provides numerous different 
services, each of which has access to this database. 
Allowing access to the database by many different enti- 

30 ties creates many opportunities for security breaches to 
occur. Therefore, what is needed is a way to improve the 
security of confidential customer information in a server 
system coupled to the Internet 

35 SUMMARY QF THE INVENTION 

A method is described of providing a document to a 
client coupled to a server. The server functions as a 
proxy on behalf of tiie client for purposes of accessing a 

40 remote server. In the method, a document is retrieved 
from the remote server in response to a request from 
ttie client The document includes data to be used by 
tiie client in generating a display The proxying server 
alters the data in the document to form a transcoded 

45 document The transcoded document is then transmit- 
ted to the client 

Other features of tiie present invention will be 
apparent from ttie accompanying drawings and from the 
detailed description which follows. 

50 

BRIEF DESCRIPTION QF THE DRAWINGS 

The present invention is illustrated by way of exam- 
ple and not limitation in the figures of the accompanying 
55 drawings, in which like references indicate similar ele- 
ments and in which: 

Figure 1 illustrates several clients connected to a 
proxying server in a network. 
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Rgure 2 illustrates a client according to the present 
invention. 

Figure 3 is a block diagram of a server according to 
the present invention. 

Figure 4A illustrates a server including a proxy s 
cache and a transcoder. 

Figure 4B illustrates databases used in a sender 
according to the present Invention. 
Figure 5 is a flow diagram illustrating a routine for 
transcoding a document retrieved from a remote io 
server using data stored in a persistent database. 
Figure 6 is a flow diagram illustrating a routine for 
transcoding an HTML document for purposes of 
eliminating bugs or undesirable features. 
Figure 7 is a flow diagram illustrating a routine for 75 
reducing latency when downloading a document 
referencing an image to a dient 
Rgure 8 is a flow diagram illustrating a routine for 
updating documents stored in tiie proxy cache 
using data stored in a persistent database. 20 
Rgure 9 is a flow dagram illustrating a routine used 
by a sender for retrieving documents from another 
remote server. 

Rgure 10 is a block diagram of a prior art sender 
system showing a relationship between various 25 
sen/ices and a database. 

Rgure 11 is a block diagram of a server system 
according to the present invention showing a rela- 
tionship between various services and a user data- 
base. 30 
Figure 12 is a flow diagram illustrating a routine 
used by a server for regulating access to various 
sennces provided by the server. 

DETAILgP DESCRIPTION 35 

A method and apparatus are described for provid- 
ing proxying and transcoding of documents in a net- 
work. In tiie following description, for purposes of 
explanation, numerous specific details are set forth in 40 
order to provide a tiiorough understanding of the 
present invention. It will be evident, however, to one 
skilled in the art tiiat tiie present invention may be prac- 
ticed witiiout these specific details. In other Instances, 
well-known st'uctijres and devices are shown in block 45 
diagram form in order to avoid unnecessarily obscuring 
the present Invention. 

The present invention includes various steps, which 
will be described below. The steps can be embodied in 
machine-executable instiuctions. which can be used to so 
cause a general-purpose or special-purpose processor 
programmed with the instructions to perform the steps. 
Alternatively, the steps of the present invention might be 
perfonned by specific hardware components tiiat con- 
tain hardwired logic for performing tiie steps, or by any ss 
combination of programmed computer components and 
custom hardware components. 



I. System Overview 

The present invention is included in a system, 
known as WebTV^, for provkiing a user with access to 
the Internet. A user of a WebTV™ client generally 
accesses a WebTV^ server via a direct-dial telephone 
(POTS, fbr "plain old telephone servtee"). ISDN (Inte- 
grated Services Digital Network), or ottier similar con- 
nection, in order to browse the Web. send and receive 
electronic mail (e-mail), and use various ottier WebTV^ 
network services. The WebTV™ network services are 
provided by WebTV™ servers using software residing 
within tiie WebTV™ servers in conjunctk>n with software 
residing witiiin a WebTV™ client. 

Rgure 1 iltusta-ates a basic configuration of ttie 
WebTV™ network according to one embodiment. A 
number of WebTV™ clients 1 are coupled to a modem 
pool 2 via direct-dial, bi-directional data connections 29. 
which may be telephone (POTS. i.e.. "plain old tele- 
phone service"). ISDN (Integrated Services Digital Net- 
worl^. or any other similar type of connection. The 
modem pool 2 is coupled typically through a router, 
such as that conventionally known in the art. to a 
number of remote servers 4 via a conventional network 
infrastructure 3, such as the Internet The WebTV™ sys- 
tem also includes a WebTV™ sender 5. which specifi- 
cally supports the WebTV™ clients 1. The WebTV™ 
clients 1 each have a connection to the WebTV™ server 
5 eitiier directly or tiirough tiie modem pool 2 and ttie 
Internet 3. Note ttiat tiie modem pool 2 is a conventional 
modem pool, such as tiiose found today throughout tiie 
world providing access to the Internet and private net- 
works. 

Note tiiat in tills desaiption. in order to fecilitate 
explanation the WebTV™ server 5 is generally dis- 
cussed as if it were a single device, and functions pro- 
vided by the WebTV™ services are generally discussed 
as being perfonned by such single device. However, ttie 
WebTV™ server 5 may actually comprise multiple phys- 
ical and logical devices connected in a distributed archi- 
tecture, and ttie various functions discussed below 
which are provided by tiie WebTV™ services may actu- 
ally be distributed among multiple WebTV™ server 
devices. 

II. Client System 

Rgure 2 illustrates a WebTV™ client 1. The 
WebTV™ client 1 includes an electronics unit 10 (here- 
inafter refenred to as Ihe WebTV™ box 10"), an ordinary 
television set 12, and a remote comrol 11 . In an alterna- 
tive embodiment of tfie present invention, the WebTV™ 
box 10 is built into the television set 12 as an integral 
unit The WebTV™ box 10 includes hardware and soft- 
ware fbr providing tiie user witti a graphical user inter- 
face, by which ttie user can access the WebTV™ 
network services, browse the Web. send e-mail, and 
ottienwise access ttie Intemet 

The WebTV™ client 1 uses ttie television set 12 as 
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a display device. The WebTV^ box 10 is coupled to the 
television set 12 by a video link 6. The video link 6 is an 
RF (rado frequency). S-video, composite video, or 
other equivalent term of video link. In the preferred 
embodiment, the client 1 includes both a standard 5 
modem and an ISDN nrKxJem. such that the communi- 
cation link 29 between the WebTV^ box 10 and the 
server 5 can be either a telephone (POTS) connection 
29a or an ISDN connection 29b. The WebTV™ box 10 
receives power through a power line 7. 70 

Remote control 1 1 is operated by the user in order 
to control the WebTV™ client 1 in browsing the Web. 
sending e-mail, and performing other Internet-related 
functions. The WebTV™ box 10 receives commands 
from remote control 1 1 via an infrared (IR) communica- rs 
tion link. In aitemative embodiments, the link between 
the remote control 1 1 and the WebTV™ box 10 may be 
RF or any equivalent mode of transmission. 

111. Server System 20 

The WebTV™ server 5 generally includes one or 
more computer systems generally having the architec- 
ture illustrated in Figure 3. It should be noted that the 
illustrated architecture is only exemplary; the present 25 
invention is not constrained to this particular architec- 
ture. The illustrated architecture includes a central 
processing unit (CPU) 50, random access memory 
(RAM) 51. read-only memory (ROM) 52, a mass stor- 
age device 53. a modem 54. a network interlace card so 
(NIC) 55, and various other input/output (I/O) devices 
56. Mass storage device 53 includes a magnetic opti- 
cal, or other equivalent storage medium. 1/0 devices 56 
may include any or all of devices such as a display mon- 
itor, keyboard, cursor control device, etc.. Modem 54 is 35 
used to communicate data to and from renxyte servers 
4 via the Internet 

As noted above, the WebTV™ server 5 may actually 
comprise multiple physical and logical devices con- 
nected in a distributed architecture. Accordingly, NIC 55 40 
is used to provide data communication with other 
devices that are part of the WebTV™ sendees. Modem 
54 may also be used to communicate with other devices 
that are part of the WebTV™ sen/ices and which are not 
located in close geographic proximity to the illustrated 45 
device. 

According to the present invention, the WebTV™ 
server 5 acts as a proxy in providing the WebTV™ client 
1 with access to the Web and other WebTV™ sendees. 
More specifically. WebTV™ server 5 functions as a so 
"caching proxy". Rgure 4A illustrates the caching fea- 
ture of the WebTV™ server 5. In Rgure 4A, the 
WebTV™ sender 5 is functionally located between the 
WebTV™ client 1 and the Internet infrastructure 3. The 
WebTV™ server 5 includes a proxy cache 65 which is ss 
functionally coupled to the WebTV™ client 1 . The proxy 
cache 65 is used for temporary storage of Web docu- 
ments, images, and other information which is used by 
frequently either the WebTV™ client 1 or the WebTV™ 



server 5. 

A document transcoder 66 is functionally coupled 
between the proxy cache 65 and the Internet infrastruc- 
ture 3. The document transcoder 66 includes software 
which is used to automatically revise the code of Web 
documents retrieved from the remote servers 4. for pur- 
poses which are described below. 

The WebTV™ service provides a document data- 
base 61 and a user database 62, as illustrated in Rgure 
4B. The user database 62 contains information that is 
used to control certain features relating to access privi- 
leges and capabilities of the user of the client 1. This 
information is used to regulate initial access to the 
WebTV™ service, as well as to regulate access to the 
individual services provided by the WebTV™ system, as 
will be desaibed below. The document database 61 is a 
persistent database which stores certain diagnostic and 
historical information about each document and image 
retrieved by the server 5, as is now described. 

A. Document Database 

The basic purpose of the document database 61 is 
that, after a document has once been retrieved by the 
server 5, the stored information can be used by the 
server 5 to speed up processing and downloading of 
that document in response to all future requests for that 
document In addition, the transcoding functions and 
various other functions of the WebTV™ service are facil- 
itated by making use of the infbmiation stored in the 
document database 61 , as will be described below. 

Referring now to Rgure 5, the server 5 initially 
receives a document request from a client 1 (step 501). 
The document request will genially result from the 
user of the client 1 activating a hypertext anchor (link) 
on a Web page. The act of activating a hypertext anchor 
may consist of clicking on underiined text in a displayed 
Web page using a mouse, for example. The document 
request will typically (but not always) include the URL 
(Unifomfi Resource Locator) or other address of the 
selected anchor. Upon receiving the document request, 
the sender 5 optionally accesses the document data- 
base 62 to retrieve stored information relating to the 
requested document (step 502). It should be noted that 
the document database 62 is not necessarily accessed 
in every casa The information retrieved from the docu- 
ment database 62 is used by the server 5 for detennin- 
ing, among other things, how long a requested 
document has been cached and/or whether tiie docu- 
ment is still valid. Tlie criteria for determining validity of 
the stored document are cfiscussed below. 

The server 5 retrieves the document from the cache 
65 if the stored document is valid: othenvise. the server 
5 retrieves the document from the appropriate remote 
server 4 (step 503). The server 5 automatically trans- 
codes tiie document as nec^sary based on tiie infor- 
mation stored in the document database 61 (step 503). 
The transcoding functions are discussed further below. 

The document database 61 includes certain histor- 
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ical and diagnostic information for every Web page ttiat 
is accessed at any time by a WebTV™ client 1 . As is well 
known, a Web page may correspond to a document 
written in a language such as HTML (Hypertext Mark- 
up Language), VRML (Virtual Reality Modelling Lan- 
guage), or another suitable language. Alternatively, a 
Web page may represent an image, or a document 
which references one or more images. According to the 
present invention, once a document or image is 
retrieved by the WebTV™ server 5 from a remote server 
4 for the first time, detailed information on this document 
or image is stored permanently in the document data- 
base 61. More specifically, for every Web page that is 
retrieved from a remote server 4, any or all of the follow- 
ing data are stored in the document database 61 : 

1) information identifying bugs (errors) or quirks in 
the Web page, or undesirable effects caused when 
the Web page is displayed by a client 1 ; 

2) relevant bug-finding algorithms: 

3) the date and time the Web page was last 
retrieved; 

4) the date and time the Web page was most 
recently altered by the author; 

5) a checksum for determining whether the Web 
page has been altered; 

6) the size of the Web page (in tenns of memory); 

7) the type of Web page (e.g., HTML document, 
image, etc.); 

8) a list of l^ertext anchors (links) in the Web page 
and corresponding URLs; 

9) a list of the most popular anchors based on the 
number of "hits" (requests from a client 1); 

10) a list of related Web pages which can be 
prefetched 

1 1) whether the Web page has been redirected to 
another renrtote server 4; 

12) a redirect address (if appropriate); 

1 3) whether the redirect (if any) is temporary or per- 
manent, and if permanent the duration of the redi- 
rect; 

14) if the Web page is an image, the size of the 
image in terms of both physical dimensions and 
memory space; 

15) the sizes of in-line images (images displayed In 
text) referenced by the document defining the Web 
page; 

16) the size of the largest image referenced by the 
document; 

17) information identifying any image maps in the 
Web page; 

18) whether to resize any images corresponding to 
the Web page; 

19) an indication of any forms or tables in the Web 
page; 

20) any unknown protocols; 

21) any links to "dead" Web pages (i.e.. pages 
which are no longer active); 

22) the latency and throughput of the remote sender 



4 on which the Web page is focated; 

23) the character set of the document; 

24) the vendor of the remote server 4 on which the 
Web page is located; 

5 25) the geographic location of the remote sender 4 
on which the Web page is located; 

26) the number of other Web pages which refer- 
ence the subject Web page; 

27) the compression algorithm used by the image 
10 or document; 

28) the compression algorithm chosen by the trans- 
coder; 

29) a value indicating the popularity of the Web 
page based on the number of hits by clients; and 

IS 30) a value indicating the popularity of other Web 
pages which reference the subject Web page. 

B. Transcoding 

20 As mentioned above, the WebTV™ services pro- 
vide a transcoder 66, which is used to rewrite certain 
portions of the code in an HTML document for various 
purposes. These purposes include: (1) correcting bugs 
in documents; (2) conrecting undesirable effects which 

25 occur when a document is displayed by the client 1 ; (3) 
improving the efficiency of transmission of documents 
from the server 5 to the client 1 ; (4) matching hardware 
decompression technology within the dient 1; (5) resiz- 
ing images to fit on the television set 12; (6) converting 

30 documents into other fomiats to provide compatibility; 
(7) reducing latency experienced by a client 1 when dis- 
playing a Web page with in-line images (images dis- 
played in text); and, (8) altering documents to fit into 
smaller memory spaces. 

35 There are three transcoding modes used by the 
transcoder 66: (1) streaming. (2) buffered, and (3) 
defenred. Streaming transcoding refers to the transcod- 
ing of documents on a line-by-line basis as they are 
retrieved from a remote server 4 and downloaded to the 

40 client 1 (i.e., transcoding "on the fly"). Some documents, 
however, must first be buffered in the WebTV^ sender 5 
before transcoding and downloading them to the dient 
1 . A document may need to be buffered before transmit- 
ting it to the dient 1 if the type of changes to be made 

45 can only be made after the entire document has been 
retrieved from the remote server 4. Because the proc- 
ess of retrieving and downloading a document to the cli- 
ent 1 increases latency and decreases throughput, it is 
not desirable to buffer all documents. Therefore, the 

so transcoder 66 accesses and uses information in the 
document database 61 relating to the requested docu- 
ment to first determine whether a requested document 
must be buffered for purposes of transcoding, before 
the document is retrieved from the remote server 4. 

55 In the defenred mode, transcoding is defen-ed until 
after a requested document has been downloaded to a 
dient 1. The deferred nrxxie therefore reduces latency 
experienced by the client 1 in receiving the document. 
Transcoding may be perfomied immediately after down- 



5 



9 



EP0811939A2 



10 



loading or any time thereafter. For example, it may be 
convergent to perform transooding during periods of low 
usage of WebTV™ services, such as at night This 
mode is useful for certain types of transcoding which 
are not mandatory. 

1. Transcoding for Bugs and Quirks 

One characteristic of some prior art Web browsers 
is that they may experience failures fcrashes") because 
of bugs or unexpected features fquirks") that are 
present in a Web document. Alternatively, quirks in a 
document may cause an undesirable result even 
though the client does not crash. TTierefbre, the trans- 
coding feature of the present invention provides a 
means for correcting certain bugs and quirks in a Web 
document. To be con-ected by the transcoder 66, bugs 
and quirks must be identifiable by software running on 
the sender 5. Consequently, the transcoder 66 will gen- 
erally only con-ect conditions which have been previ- 
ously discovered, such as those discovered during 
testing or reported by users. Once a bug or quirk is dis- 
covered, however, algorithms are added to the trans- 
coder 66 to both detect the bug or quirk in the future in 
any Web document and to automatically correct it. 

TTiere are countless possibilities of bugs or quirks 
which might be encountered in a Web document 
Therefore, no attempt will be made herein to provide an 
exhaustive list. Nonetheless, some examples may be 
useful at this point Consider, for exanple. an HTML 
document that is downloaded from a remote server 4 
and which contains a table having a width specified in 
the document as "0." This condition might cause a fail- 
ure if the client were to attempt to display the document 
as written. This situation therefore, can be detected and 
corrected by the transcoder 66. Another example is a 
quirk in the document which causes quotations to be 
terminated with too many quotation marks. Once the 
quirk is first delected and an algorithm is written to rec- 
ognize it, the transcoder 66 can automatically conrect 
the quirk in any document. 

If a given Web document has previously been 
retrieved by the server 5, there will be information 
regarding that document available in the document 
database 61 as described above. TTie information 
regarding this document will include whether or not the 
document included any bugs or quirks that required 
transcoding when the document was previously 
retrieved. TTie transcoder 66 utilizes this information to 
determine whether (1) the document is free of bugs and 
quirks. (2) the document has bugs or quirks which can 
be remedied by transcoding on the fly. or (3) the docu- 
ment has bugs or quirks which cannot be corrected on 
the fly (i e., buffering is required). 

Figure 6 illustrates a routine for transcoding a Web 
document for purposes of eliminating bugs and quirks. 
Initially, the server 5 receives a document request from 
the client 1 (step 601). Next, the document database 61 
is accessed to determine whether or not the requested 



document has been previously retrieved (step 602). If 
the document has not been previously retrieved, then 
the server 5 retrieves the document from the remote 
server 4 (step 609). Next the retrieved document is 

5 analyzed for the presence of bugs or unusual conditions 
(step 61 0). Various diagnostic information is then stored 
in the document database 61 as a result of the anatys'^ 
to note any bugs or quirks that were found (step 61 1). If 
any bugs or quirks were found which can be corrected 

10 by the transcoder 66. the document is then transcoded 
and saved to the proxy cache 65 (step 612). The ti^ns- 
coded document is tiien downloaded to the client 1 
(step 613). It should be noted that transcoding can be 
deferred until after the document has been downloaded. 

15 as described above: hence, the sequence of Figure 6 is 
illustrative only 

If (in step 602) the requested document f^d been 
previously retieved, then it is determined whether the 
requested document is still valid (step 603) and whether 

20 ttie document is present in tiie proxy cache 65 (step 
604). If tiie document is no longer valid, then tiie docu- 
ment is retrieved from tiie remote server 4. analyzed for 
bugs and quirks, transcoded as required, and then 
downloaded to the client 1 as described above (steps 

25 610-613, step 607). Metiiods for determining validity of 
a document are discussed below. If the document is still 
valid (step 603) and the document is present in tiie 
cache 65, the document is downloaded to the dient 1 in 
Its current form (as it is stored in the cache), since it has 

30 already been transcoded (step 608). 

The document, however, may be valid buX not 
present in ttie cache. This may be the case, for exam- 
ple, if tiie document has not been requested recentty 
and ttie cache 65 has become too full to retain tiie 

35 requested document In ttiat case, the document is 
retrieved again from ttie remote sender 4 (step 605) and 
ttien transcoded on ttie basis of the previously^cquired 
diagnostic information stored wittiin tiie database 61 for 
ttiat document. The document Is ttien saved to ttie 

40 cache 65 (step 606). Note that because ttie document is 
still valid, it is assumed that ttie diagnostic information 
stored in ttie document database 61 for that document 
is still valid and that ttie transooding can be performed 
on tiie basis of that information. Accordingly, once ttie 

45 document is t^nscoded, tiie transcoded document is 
downtoaded to the dient 1 (step 607). Again, note that 
transooding can be deferred until after ttie document 
has been downloaded in some cases. 

The validity of the requested document can be 

so determined based on various different criteria. For 
example, some HTML documents specify a date on 
which the document was created, a length of time for 
which ttie document will be valid, or botti. The validity 
determination can be based upon such infomiation. For 

55 example, a document which specifies only ttie date of 
creation can be automatically deemed invalid after a 
predetermined period of time has passed. 

Alternatively, validity can be based upon ttie popu- 
larity of ttie requested document. "Popularity" can be 
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quantified based upon the number of lifts for that docu- 
ment, which is tracked in the document database 61. 
For example, it might be prudent to simply assign a rel- 
atively short period of validity to a document which is 
very popular and a longer period of validity to a docu- 
ment which is less popular. 

Another alternative basis Ibr the validity of a docu- 
ment is the obsen/ed rate of change of the document. 
Again, data in the persistent document database 61 can 
be used. That is, because the document database 61 
stores the date and time on which the document was 
last obsen/ed to change, the server 5 can approximate 
how often the document actually changes. A document 
or image which is observed to change frequently (e.g., 
a weather map or a news page) can be assigned a rel- 
atively short period of validity. It will be recognized that 
numerous other ways of determining validity are possi- 
ble. 

2. Transcoding to Reduce Latency 

Another purpose for transcoding is to allow docu- 
ments requested by a client 1 to be displayed by the cli- 
ent 1 more rapidly Many HTML documents contain 
references to "in-line" images, or images that will be dis- 
played in text in a Web page. The normal process used 
in the prior art to display a Web page having in-line 
images is that the HTML document referencing the 
image is first downloaded to the client, followed by the 
client's requesting the referenced image. The refer- 
enced image is then retrieved from the remote server on 
which it is located and downloaded to the client One 
problem associated with the prior art, however, is that 
the speed with which a complete Web page can be dis- 
played to the user is often limited by the time it takes to 
retrieve in-line images. One reason for this is that it sim- 
ply takes time to retrieve the image itself after the refer- 
encing document has been retrieved. Another reason is 
that, in the prior art, if the referencing document does 
not specify the size of the image, the Web page gener- 
ally cannot be displayed until the image itself has been 
retrieved. The present invention overcomes these limi- 
tations. 

According to the present invention, information 
stored in the document database 61 regarding the in- 
line images is used to transcode the referencing docu- 
ment in order to reduce latency in displaying the Web 
page. Once any document which references an in-line 
image is initially retrieved by the server 5, the fact that 
the document references an in-line image is stored in 
the document database 61. In addition, the size of the 
image is determined, either from the document (if spec- 
ified) or from the image itself, and then stored in the 
document database 61. Consequentiy. for documents 
which do not specify the size of tiieir in-line images, the 
size information stored in the database 61 is then used 
the next time the document is requested in order to 
reduce latency in downloading and displaying the Web 
page. 



Refer now to Rgure 7, which illustrates a routine for 
reducing latency when downloading a document refer- 
encing an image to a client 1. Assume tiiat a client 1 
sends a request to the server 5 for an HTML document 

5 containing a reference to an in-line image. Assume fur- 
ther tiiat the size of the image is not specified in the doc- 
ument itself. Initially, the server 5 determines whether 
that document has been previously retrieved (step 701). 
If not, tiie standard initial retrieval and transcoding pro- 

10 cedure is followed (step 706), as described in connec- 
tion with Figure 6. If, however, the document has been 
previously retrieved, then tiie transcoder 66 accesses 
the size information stored in the document database 
61 for the in-line image (step 702). Based on this size 

15 information, the HTML document is transcoded such 
that, when the Web page is initially displayed by the cli- 
ent 1, the area in which the image belongs is replaced 
by a blank region enveloping the shape of the image. 
Thus, any in-line image referenced by a document is 

20 displayed initially as a blank region. Consequently, the 
client 1 can immediately display the Web page con^e- 
sponding to the HTML document even before the refer- 
enced image has been retrieved or downloaded (i.e., 
even before the size of the image is known to the dient 

25 1). 

As tiie transcoded HTML document is downloaded 
to the client, the image is retrieved from tiie appropriate 
remote server 4 (step 704). Once tiie image is retrieved 
from the rewoXe server 4 and downloaded to ttie client 
30 1 , tiie client 1 replaces tiie blank area in the Web page 
with tiie actual image (step 705). 

3. Transcoding to Display Web Pages on a Television 

35 As noted above, the client 1 utilizes an ordinary tel- 
evision set 12 as a display device. However, images in 
Web pages are generally formatted for display on a 
computer monitor, not a television set. Consequentiy. 
tiie transcoding function of the present invention is used 

40 to resize images for display on the television set 1 2. This 
includes reseating images as necessary to avoid trunca- 
tion when displayed on the television set 1 2. 

It shoukJ be noted that prior art Web browsers 
which operate on computer nfX)nitors typically use resiz- 

45 able windows. Hence, tiie size of tiie visible region var- 
ies from client to client. However, because the web 
browser used by the WebTV™ client 1 is specifically 
designed for display on a television set, the present 
invention allows documents and images to be formatted 

so when they are cached. 

4. Transcoding for Transmission Efficiency 

Documents retrieved by the server 5 are also ti^ans- 
55 coded to improve transmission efficiency. In particular, 
documents can be t-anscoded in order to reduce high 
frequency components in order to reduce interlace 
flicker when they are displayed on a television set. 

Documents can also be transcoded in order to 
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lower the resolution of the displayed Web page. Reduc- 
ing the resolution Is desirable, because images format- 
ted for computer systems will generally have a higher 
resolution than the NTSC (National Tele^ion Stand- 
ards Committee) video format used by conventional tel- 5 
evision sets. Since the NTSC video does not have the 
bandwidth to reproduce the resolution of computer-for- 
matted images, the bandwidth consumed in transmitting 
images to the client 1 at such a high resolution would be 
wasted. 10 

5. Other Uses for Transcoding 

Transcoding is also used by the present invention to 
recede a document using new fbmiats into older, com- is 
patiUe formats. Images are often displayed in the JPEG 
(Joint Picture Experts Group) format or the GIF image 
format. JPEG often consumes less bandwidth than GIF. 
however. Consequently, images which are retrieved in 
GIF format are sometimes transcoded into JPEG for- 20 
mat. Methods for generally converting images between 
GIF and JPEG formats are well known. 

Other uses for transcoding include transcoding 
audio files. For example, audio may be transcoded Into 
different formats in order to achieve a desired balance 25 
between memory usage, sound quality, and data trans- 
fer rate. In addition, audio may be transcoded from a f fle 
format (e.g., an ".AU" file) to a streaming format (e.g.. 
MPEG 1 audio). Yet another use of audio transcoding is 
the transcoding of MIDI (Musical Instrument Digital 30 
Interface) data to streaming variants of MIDI. 

Additionally, documents or images requiring a large 
amount of memory (e.g.. long lists) can be transcoded 
in order to consume less memory space in the client 1. 
This may involve, for example, separating a large docu- 35 
ment or image into multiple sections. For example, the 
server 5 can insert tags at appropriate locations in the 
original document so that the document appears to the 
client 1 as multiple Web pages. Hence, while viewing a 
given page representing a portion of the original docu- 40 
ment, the user can view the next page (i.e., tiie next por- 
tion of the original document) by activating a button on 
the screen as if it were an ordinary hypertext anchor. 

C. Proxying 45 

As noted above, the server 5 functions as a proxy 
on behalf of the client 1 for purposes of accesang the 
Web. The document database 61 is used In various 
ways to facilitate this proxy role, as will now be so 
descnbed. 

1. Updating Cached Documents 

It is desirable to store frequentiy-requested HTML ss 
documents and images in the proxy cache 65 to furtiier 
reduce latency in providing Web pages to the client 1. 
However, because some documents and images 
change over time, documents in the cache 65 will not be 
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vaJid indefinitely, as mentioned above. A weather map 
or a news-related Web page, for example, are likely to 
be updated quite frequentiy Consequently, it is desira- 
ble for the server 5 to have the ability to estimate the fre- 
quency witti which documents change, in order to 
determine how long a document can safely remain 
within tiie proxy cache 65 without being updated. 

The persistent database 65 is used to store the 
date and time of the last several fetches of each docu- 
ment and image retrieved from a remote server 4, along 
with an indication of any changes that were detected, if 
any. A document or image which has been stored in the 
cache 65 is then retrieved on a periodic basis to deter- 
mine if it has been changed. Change status information 
indicating whettier the document has changed since the 
previous fetch is then stored in the document database 
65. If no changes are detected, then the time interval 
between fetches of this document is increased. If tiie 
document has changed, the time interval is maintained 
or decreased. As a result items in tiie cache 65 which 
change frequentiy will be automatically updated at fre- 
quent intervals, whereas documents which do not 
change often will be replaced in the cache less fre- 
quentiy 

Rgure 8 illustrates a routine for updating docu- 
ments stored in the proxy cache 65 using data stored in 
. the document database 61 . Assume a document X has 
been stored in the proxy cache 65. Document X 
remains in the cache 65 until a predetermined update 
period T^ expires (step 801). Upon the expiration of the 
update period T^, tiie document X is again retrieved 
from ttie appropriate remote sender 4 (step 802). The 
newly-retrieved document X is then compared to the 
cached version of document X (step 803). If ttie docu- 
ment has changed, then the cached version of docu- 
ment X is replaced with the newly-retrieved version of 
document X (step 806). If not. then the update period T^ 
is inaeased. according to a predetermined time incre- 
ment At^ (step 804). In any case, the date and time and 
the change status of document X is saved to the docu- 
ment database 61 (step 805). 

Document and Image Prefetching 

The document database 61 is also used by the 
server 5 to store prefetching information relating to doc- 
uments and images. In particular, the database stores, 
for each document that has been retrieved, a list of 
images referenced by the document if any, and their 
locations. Consequentiy, the next time a document is 
requested by a client 1 . the images can be immediately 
retrieved by the server 5 (from the cache 65, if available, 
or from the remote server 4). even before the client 1 
requests tiiem. This procedure improves the speed with 
which requested Web pages are downloaded to the cli- 
ent. 

The document database 61 is also used to facilitate 
a process referred to as "server-advised client prefetch- 
ing." Server-advised client prefetching allows the server 
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5 to inform the client 1 of documents or images which 
are popular to allow the client 1 to perform the prefetch- 
ing. In particular, tor any given document, a list is main- 
tained in the sender 5 of the most popular hypertext 
anchors in that document (i.e.. those which have previ- 5 
ously received a large number of hits). When that docu- 
ment is requested by the client 1 , the server 5 provides 
the client 1 with an indication of these popular links. 

3. Redirects 10 

Web pages are sometimes fonA/arded from the 
remote server on which they are initially placed to a dif- 
ferent location. Under the HTTP (Hypertext Transport 
Protocol), such fonwarding is sometimes referred to as a 75 
"redirect." When an HTML document is initially stored 
on one remote server and then later transferred to 
another remote server, the first remote server will pro- 
vide, in response to a request for that document, an 
indicatfon that the document has been transferred to a 20 
new remote server. This indication generally includes a 
fonwarding address ("redirect address"), which is gener- 
ally a URL 

In the prior art, when a computer requesting a Web 
page receives a redirect, it must then submit a new 25 
request to the redirect address. Having to submit a sec- 
ond request and wait for a second response consumes 
time and increases overall latency Consequently, the 
present invention uses the document database 61 to 
store any redirect address for each document or image. 30 
Any time a redirected document is requested, the sender 
5 automatically accesses the redirect address to 
retrieve the document. The document or image is pro- 
vided to the client 1 based on only a single request from 
the client 1. The change in location of the redirected 35 
document or image remains completely transparent to 
the client 1. 

Figure 9 illustrates a routine performed by the 
server 5 in accessing documents which may have been 
fonwarded to a new remote server. Initially, the server 5 40 
receives a request for a document, which generally 
includes an address (step 901). The server 5 then 
accesses the document database 65 to determine 
whether there is a redirect address for the requested 
document (step 902). If there is no redirect address, 45 
then the server 5 accesses a remote server 4 based on 
the address provided in the document request from the 
client 1 (step 903). Assuming that the remote server 4 
does not respond to the server 5 with a redirect (step 
904), the document is retrieved and downloaded to the so 
client 1 by the server 5 (step 907). If, however, a redirect 
address was stored in the document database 65 (step 
902). then the server 5 accesses the requested docu- 
ment according to the redirect address (step 906). Or, if 
the remote server 4 responded with a redirect (step ss 
904), then the server 5 saves the redirect address to the 
document database 61 (step 905) and accesses the 
requested document according to the redirect address 
(step 906). 



4. Other Proxy Functions 

The document database 65 also stores information 
relating to the performance of each remote server 4 
from which a document is retrieved. This information 
includes the latency and throughput of the remote 
server 4. Such Information can be valuable in instances 
where a remote server 4 has a history of responding 
slowly For example, when the document is requested, 
this knowledge can be used by the server 5 to provide a 
predefined signal to the client 1. The client 1 can, in 
response to the signal, indicate to the user that a delay 
is likely and give the user the option of canceling the 
request. 

5. Backoff Mode 

Although the server 5 generally operates in the 
proxy mode, it can also enter a "backoff mode" in which 
the server 5 does not act as a proxy, or the server 5 per- 
forms only certain aspects of the nonnal proxying func- 
tions. For example, if the proxy cache 65 is overloaded, 
then the server 5 can enter a backoff mode in which 
documents are not cached but are transcoded as 
required. Alternatively, during times when the server 5 is 
severely overloaded with network traffic, the server 5 
may instruct the client 1 to bypass the server 5 and con- 
tact remote servers 4 directly for a specified time or until 
further notice. Or, the sender 5 can enter a flexible back- 
off mode in which the client 1 will be instructed to con- 
tact a remote server 4 directly only for certain Web sites 
for a limited period of time. 

D. Access to WebTV™ Services 

The WebTV™ server 5 provides various sen^ices to 
the client 1, such as proxying and electronic mail ("e- 
mair). In the prior art. certain difficulties are associated 
with allowing a client computer access to different serv- 
ices of an Internet service, as will now be explained with 
reference to RgurelO. 

Rgure 10 Illustrates a client-s^er system accord- 
ing to one prior art embodiment. The server 76 provides 
various sen^ices A, B, and C. The server 76 includes a 
database 71 for storing information on the user's access 
privileges to services A, B, and C. The client 75 of the 
embodiment of Rgure 10 accesses any of services A, 
B. and C by contacting that service directly The con- 
tacted service then accesses the database 71. which 
stores the access privileges of the client 75, to deter- 
mine whether the client 75 should be allowed to access 
that service. Hence, each service provided by the 
server 76 requires direct access to the database 71. 
This architecture results in a large number of accesses 
being made to the database 71 , which is undesirable. In 
addition, the fact that each service independently has 
access to the database 71 raises security concerns. 
Specifically, it can be difficult to isolate sensitive user 
information. The present invention overcomes such dif- 
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ficuHies using a technique which is new described. 
1. Tickets Containing Privileges And Capabilities 

As shewn in Figure 11, the sender 5 provides a 
number of services D, E, and F, and a log-in service 78. 
The log-in service is used specifically to control initial 
log-on procedures by a client 1. The log-in service 78 
has exclusive access to the user database 62 (dis- 
cussed above with respect to Rgure 4B). The lognn 
service 78 and the user database 62 are located within 
a first security zone 84. Sendee D is located within a 
second security zone 86, while services E and F are 
contained within a third security zone 88. Note that the 
specific arrangement of security zones 84, 86, and 88 
with respect to services D, E, and F is illustrative only 

The user database 66 of the present invention 
stores various information pertaining to each authorized 
user of a client 1. This information includes account 
information, a list of the WebTV™ that services are 
available to the particular user, and certain us^ prefer- 
ences. For example, a particular user may not wish his 
client 1 to be used to access pages having adult- 
oriented subject matter. Consequently, the user would 
requ^ that his account be filtered to prevent access to 
such material. This request would then be stored as 
part of the user data in the user database 66. 

With regard to user preferences, the hypertext links 
selected by a given user can be tracked, and those hav- 
ing the largest number can be stored in the user data- 
base 66. The list can then be provided to the client 1 for 
use in generating a menu screen of the user's favorite 
Web sites, to allow the user to directly access those 
W^ sites. The list can also be used by the server 5 to 
analyze the user's interests and to formulate and pro- 
vide to the user a list of new Web sites whteh the user is 
likely to be interested in. The list might be composed by 
associated key words in Web pages selected by the 
user with other Web pages. 

Refenring again to Rgure 11, in response to a log- 
on request by a client 1, the log-in service 78 consults 
the user database 62 to determine rf access to the 
server 5 by this particular client 1 is authorized. Assum- 
ing access is authorized, the log-in service 78 retrieves 
certain user information pertaining to this particular cli- 
ent 1 from the user database 62. The log-in sennce then 
generates a "ticket" 82, which is an information packet 
including the retrieved information. The ticket 82 is ttien 
provided to the client 1 which requested access. 

The ticket 82 includes all information necessary to 
desaibe ttie access privileges of a particular user with 
respect to all services provided by the server 5. For 
example, the ticket may include the user name regis- 
tered to the client 1 , tiie e-mail address assigned to cli- 
ent 1, and any filterir^ requested by the user with 
respect to viewing Web sites. Each time the user 
requests access to one of tiie services D, E. or F, the cli- 
ent 1 submits a copy of ttie ticket 82 to that service. The 
requested service can then determine from the copy of 



the ticket 82 wheUier access to that service by tiiat cli- 
ent 1 is autiiorized and, if so. any important information 
relating to such access. 

None of tiie services provided by tiie server 5, other 

5 than the log-in service 78. has access to ttie user data- 
base 62. Hence, any security-sensitive information can 
be isolated wittiin tiie user database 62 and tiie log-in 
service 78. Such isolation allows the individual services 
provided by tiie server 5 to be placed within separate 

10 "firewalls" (security regions), illustrated as security 
zones 84. 86, and 88. In addition, ttiis technique greatiy 
reduces the number of accesses required to ttie user 
database 62 compared to ttie prior art embodiment 
illustrated in Figure 10. 

15 

2. Redundancy of Services and Load Balancing 

The present invention also includes certain redun- 
dancies in ttie various services provkJed by the server 5. 

20 In particular, a given service (e.g., e-mail) can be pro- 
vided by more than one physical or logical device. Each 
such device is considered a "proYider" of that sennce. If 
a given provider is overioaded, or if the client 1 is unable 
to contact that provkier, tiie client 1 can contact any of 

25 the other providers of tiiat service. When tiie server 5 
receives a log-in request from a client 1, in addition to 
generating ttie above-described ticket 82, the log-in 
service 78 dynamically generates a list of available 
WebTV^ services and provides tiiis list to tiie client 1 . 

30 The server 5 can update tiie list of servtees used by 
any client 1 to refl^ savices becoming unavailable or 
services coming on-line. Also, tiie list of services pro- 
vided to each client 1 can be updated by the server 5 
based upon changes in ttie loading of tiie server 5, in 

35 order to optimize traffic on ttie server 5. In addition, a cli- 
ent's list of sennces can be updated by services other 
ttian the log-in service 78, such that one service can 
effectively introduce another sendee to the client 1 . For 
example, ttie e-mail service may provide a client 1 witii 

40 ttie name, port number and IP of its address book serv- 
ice. Thus, one service can effectively, and securely 
wittiin the same chain of trust, introduce anottier sen^e 
to the client 1. 

This list of services includes ttie name of each serv- 

45 ice, a port number for the provider of each service, and 
an IP (Intemet Protocol) for each service. Different pro- 
viders of ttie same sendee are designated by ttie same 
name, but different port numbers and/or IPs. Note that 
in a standard URL, the protocol is normally specified at 

50 ttie beginning of the URL, such as "HTTPyMww...." 
under ttie HTTP protocol. Hewwer, according to tiie 
present invention, tiie nomial protocol designation (i.e., 
"HTTP") in tiie URL Is replaced with the name of ttie 
service, since ttie port number and IP for each sennce 

55 are known to ttie client 2. Hence, ttie client 1 can access 
any of ttie redundant providers of a given service using 
ttie same URL This procedure effectively adds a level 
of indirection to all accesses made to any WebTV^ 
service and automatically adds redundancy to ttie proxy 
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service. It should also be noted that separate service 
names can also refer to the same service. 

Assume, for example, that the e-mail service pro- 
vided by the WebTV™ system is designated by the serv- 
ice name 'WTV-maiito." A client 1 can access any s 
provider of this e-mail sendee using the same URL The 
client 1 merely chooses the appropriate port number 
and IP number to distinguish between providers. If the 
client 1 is unable to connect to one e-mail provider, it 
can simply contact the next one in the list. io 

Thus, at log-in time, a client 1 is provided with both 
a ticket containing privileges and capabilities as well as 
a list of service providers, as illustrated In Rgure 12. Ini- 
tially the log-in service 78 determines whether the user 
of client 1 is a valid user (step 1201). If not, log-in is is 
denied (step 1205). If the user Is a valid user, then the 
log-in service 78 gathers user information from the user 
database 62 and generates a ticket 82 (step 1202). The 
log-in service 78 also generates the above-described 
list of sendees (step 1203). The ticket 82 and the list of 20 
services are then downloaded to the client 1 (step 
1204). 

3. Asynchronous Notification to Clients by Server 

25 

Another limitation associated with prior art Internet 
servers is the inability to provide asynchronous notifica- 
tion information to the client in the absence of a request 
from the client to do sa It would be desirable, for exam- 
ple, for a server to notify a client on Its own initiative 30 
when a particular Web page has changed or that a par- 
ticular service Is inaccessible. The server 5 of the 
present invention provides such capability, and the cli- 
ent 1 is configured to receive and decode such notifica- 
tions. For example, the client 1 can receive updates of 35 
its listing of sennce providers from the server 5 at vari- 
ous points in time, as already described. Similarly, if a 
particular service provider becomes unavailable, that 
fact will be automatically communicated to the client 1 . 
As anotiier exanple, if e-mail addressed to tiie user has 40 
been received by the sender 5. then the sender 5 will 
send a message to tiie client 1 indicating this fact. The 
client 1 will tiien notify the user that e-mail Is waiting by 
a message displayed on the television set 12 or by an 
LED (light emitting diode) built into the housing of 4s 
WebTVTwboxlO. 

Thus, a method and apparatus have been 
described for providing proxying and transcoding of 
documents in a network. Although the present invention 
has been described with reference to specific exem- so 
plary embodiments, it will be evident tiiat various modi- 
fications and changes may be made to tiiese 
embodiments without departing from the broader spirit 
and scope of the invention as set forth in tiie claims. 
Accordingly, tiie specification and drawings are to be ss 
regarded in an illustrative rather tiian a restrictive sense. 



Claims 

1. In a proxying server coupled to a client and to a 
remote server, the proxying server operating as a 
proxy on behalf of the client for accessing tiie 
remote server, a metiiod of providing a first docu- 
ment to tiie client, tiie meUiod comprising the steps 
of: 

retrieving tiie first document from the remote 
server in response to a request from the client, 
the document including data for causing the cli- 
ent to generate a display; 
using ttie proxying server to alter the data in tiie 
first document to form a transcoded document; 
and 

transmitting the transcoded document to tiie 
client 

2. A method according to claim 1 . wherein the step of 
using ttie proxying sender to alter tiie data in tiie first 
document comprises tiie steps of: 

analyzing ttie data to determine whetiier a pre- 
determined condition is present in tiie data, 
wherein the predetermined condition com- 
prises data which, when used by ttie client, 
causes an enror condition to occur; and 
if the predetermined condition is present in tiie 
data, revising the data to eliminate tiie prede- 
temiined condition. 

3. A method according to daim 1 , wherein the step of 
transmitting ttie transcoded document to the client 
is performed prior to performing tiie step of using 
ttie proxying server to alter ttie data in ttie first doc- 
ument. 

4. A mettiod according to claim 1. wherein the client 
includes a television display, wherein the document 
references an image, and wherein the step of using 
ttie proxying server to alter ttie data in the docu- 
ment comprises the step of revising ttie data such 
that the image is sized for display on tiie television 
display 

5. A mettiod according to claim 1 , furtiier comprising 
the steps of: 

retrieving an Image from the remote server In 
response to a request from the client, wherein 
the image has a first image format: and using 
the proxying server to convert the image from 
the first image format to a second image for- 
mat. 

6. A mettiod according to daim 1, wherein the first 
document indudes a link to a second document, 
ttie link Induding a first address, and wherein ttie 
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step of using the proxying server to atter the data in 
the document comprises the step of updating the 
link. 

7. A method according to daim 6, wherein the second s 
document is an image, and wherein the step of 
updating the link includes the step of addng infor- 
mation to the first document indicating the size of 
the image. 

10 

8. A method according to daim 6. wherein the second 
document is inaccessible to the proxying server, 
and wherein the step of updating the link comprises 
the step of removing the link 

15 

9. A method according to daim 6. wherein the second 
document has been relocated from the first address 
to a redirect address, and wherein the step of 
updating the link comprises the step of updating the 
link to con'espond to the redirect address. zo 

10. A method according to daim 1, further comprising 
the steps of: 

identifying an image referenced by the docu- 2S 
ment; 

determining whether the image has been previ- 
ously retrieved by the proxying server; and 
if the image has been previously retrieved by 
the proxying server, accessing information so 
stored in the proxying server indicating the size 
of the image; 

wherein the step of using the proxying server to 
alter the data in the document comprises the step ss 
of using the information indicating the size of the 
image to revise the data of the document to allow 
the document to be displayed by the dient before 
the image is received by the dient 
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11. In a server coupled to a dient and to a remote 
server, a method of providing proxy sendees to the 
dient for accessing a document stored in the 
remote server, the document induding data to be 
used by the client to provide a display, the method 4S 
comprising the steps of: 

providing a persistent database in the server, 
the persistent database induding information 
relating to the document; and so 
using the Information stored in the persistent 
database to guide the proxying sendees. 

1 2. A method according to daim 1 1 , further comprising 
the step of transcoding the document based on the ss 
information stored in the persistent database to 
generate a transcoded document. 

13. A method according to daim 12, further comprising 



the step of providing the transcoded document to 
the client, wherein the step of providing the trans- 
coded document to the client is performed prior to 
performing the step of transcoding. 

14. A method accading to claim 12, wherein the per- 
sistent database indudes information correspond- 
ing to a plurality of en-or conditions, the method 
further comprising the steps of: 

analyzing the data in the document using the 
information stored in the persistent database to 
determine whether the data is likely to cause 
one of the error conditions to occur when used 
by the client; and 

automatically revising the data if the data Is 
determined in tiie analyzing step to be likely to 
cause one of the error conditions to occur when 
used by the dient 

15. A method according to daim 1 1 , further comprising 
the step of storing in the persistent database valid- 
ity information corresponding to the document 

16. A method according to claim 15, wherein the valid- 
ity information is based on an obsen^ed rate of 
change of the document. 

1 7. A method according to daim 1 1 . f urtiier comprising 
the step of Storing in the persistent database per- 
formance Information relating to performance of the 
rerTX>te server when accessing ttie document. 

ia A method according to claim 17 wherein the per- 
formance information is a latency value. 

19. A method according to daim 1 1 , f urtiier conprising 
the step of storing in the persistent database infor- 
mation for optimizing memory usage by the client. 

20. In server coupled to a client, the dient having an 
authorized user, wherein the server is for providing 
the dient witii a plurality of on-line sendees includ- 
ing a log-in service and a second sendee, the 
server inducting a user database, a method of con- 
trolling access by the dient to tiie plurality of on-line 
services, the method comprising the steps of: 

storing in the database a set of user data con^e- 
sponding to the authorized user; 
using the log-in service to recave a first access 
request from the dient, the first access request 
for initiating access to the server by the dient; 
generating an Information packet from the set 
of user data, the information packet indicating 
access privileges of the autiiorized user in rela- 
tion to tiie plurality of on-line services; 
using the log-in service to provide the informa- 
tion packet to the client; 
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using the second service to receive a second 
access request from the client, the second 
access request for requesting use of the sec- 
ond service by the client, the second access 
request including a copy of the information $ 
pacl<et; and 

using the copy of the information packet to reg- 
ulate access by the client to the second serv- 
ice. 

10 

21 . A method according to claim 20, wherein the plural- 
ity of on-line services are Internet services. 

22. A method according to claim 20. wherein the sec- 
ond service is a proxy service by which the server is 
functions as a proxy on behalf of the client for pur- 
poses of accessing a second server. 

23. In server system coupled to a client, a method of 
providing the client with a plurality of redundant 20 
services, each of the redundant services being sub- 
stantially equivalent to each of the other redundant 
services, the method comprising the steps of: 

providing the client with a service name appli- 
cable to all of the redundant services; 
providing the client with a unique port number 
for each service; 

providing the client with a unique protocol for 
each service; 

receiving a request to access one of the redun- 
dant services from the client, the request 
including an address specifying the service 
name; and 

granting access to one of the redundant serv- 
ices in accordance with the name included in 
the address, one of the port numbers and one 
of the protocols, such that the client uses the 
same address to access any of the redundant 
sen/ices. 

24. A method according to claim 1, wherein the 
address is a URL (Uniform Resource Locator) 
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